People resist change. Whether due to inertia or fear of the unknown, people will often actively oppose change, or at least slow it down to what they feel is a manageable pace. In order to change an organization, you must understand these forces and channel them to enable rather than oppose change. 

"Nothing is more difficult than to introduce a new order. Because the innovator has for enemies all those who have done well under the old conditions and lukewarm defenders in those who may do well under the new." ù Niccol≥ Machiavelli, 1513 A.D.

In its simplest form, we view the forces of change as a formula:

pain + desire = change

The fundamental tenet of this formula is that ultimately change is driven by emotions. Pain and desire are the forces that drive us to make a change and to accept it. Pain is the catalyst that initiates a change, whereas desire is the force that pulls us towards a goal. A successful transition entails understanding and managing the perceived level of pain and the desire for a solution. This is what D. Connor [CON92] calls pain management and remedy selling.

Pain management identifies and communicates what the real problem is and why it's necessary to change. Sometimes finding the root cause of a problem can be very hard yet, in the final analysis, it's very valuable to initiate the change. It has been our experience that many of the root causes of problems are in the process or, rather, in the absence of process.

Remedy selling contains two activitiesùsolution selling and transition planning. It isn't enough to describe the ideal goal. To define a solution, you also need to have a path from the current point to that goal with some clearly defined intermediate points.

The change will not happen just because management says so. You must identify the agents of changeùthat set of individuals who will take on the mission to make the change happen.

The change agents must understand the pain, formulate the real nature of the problem, and communicate it to the organization so it becomes very aware of its pain. Then, the change agents must formulate and describe both the goal, and the path to the goal, and again communicate it to the various parts of the organization. This communication is complicated. It is too easy to generalize about both problems and solutions. "Everybody must be a team player " is a sweeping generalization about how individuals need to act, however, it does little to initiate change. To affect change, the change agentsùthe championsùmust communicate in terms of tangible, quantifiable activities. J. Jellison [JEL93] speaks about levels of language:

  • At 30,000 feetùindictment of ability:
    The focus will only be on the problem, or even symptoms of the problems, not on the solution. "The development group does not have a sufficient understanding of object technology."
  • At 20,000 feetùhigh level solution:
    Still very few concrete things with which to start any action. "You need to improve communication between teams."
  • At 10,000 feet: specific actions but no qualification of scope.
    "Construct a use case model to capture the functional requirements of the next generation system."
  • At ground levelùconcrete requests:
    Actions and measurements are communicated. At this level, you are down to exactly what the organization needs to do. "The design of each subsystem will contain from 1 to 3 class diagrams, with some 7 to 10 classes."

The correct ground level naturally depends on to whom in the organization the message is addressed. The real value of a change agent is to be able to understand the overall solution, and then to articulate each step using ground level language and focusing on one change at a time.

To successfully implement a process change, the adopting organization must:

  • Identify change agents at various levels in the organizations.
  • Plan the change in small, reasonable, and measurable steps.
  • Communicate the changes using ground level language appropriate to the level of organization.

When you're changing the process, this is the role of the process implementation plan.

 

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process